fix: allow user-defined interfaces as Server Props - #412
Conversation
Interfaces do not get implicit index signatures in TypeScript, so the Record<string, unknown> bound on Props rejected them with 'Index signature for type string is missing' (surfaced downstream as cloudflare/agents#1886). Bound Props by 'object' on Server, getServerByName, and routePartykitRequest. The T constraints on the latter two become Server<Env, object>: the #_props private field carries Props covariantly, so a subclass declaring interface Props failed the old Server<Env> constraint, and the DO stub's setName param resolved to the constraint's Record type. Defaults stay Record<string, unknown> so untyped usage still reads props values as unknown.
🦋 Changeset detectedLatest commit: de5bc27 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
hono-party
partyfn
partyserver
partysocket
partysub
partysync
partytracks
partywhen
y-partyserver
commit: |
| Env extends Cloudflare.Env = Cloudflare.Env, | ||
| T extends Server<Env> = Server<Env>, | ||
| Props extends Record<string, unknown> = Record<string, unknown> | ||
| T extends Server<Env, object> = Server<Env>, |
There was a problem hiding this comment.
shouldn't this be Server<Env, Props> to ensure that the props relate to the same type than the server type ?
Or maybe inferring the default Props type from the Server type instead ?
| routePartykitRequest(request, env, { props: authProps }); | ||
|
|
||
| // ============================================ | ||
| // NEGATIVE TESTS - non-object props stay rejected |
There was a problem hiding this comment.
This should have a negative test where you pass an object to props, but with a structure not matching AuthProps (i.e. missing the userId for instance), to validate that it actually provides type safety (the existing negative tests are probably already passing with the old version of types)
2 participants
Summary
The
Propsgeneric onServer,getServerByName, androutePartykitRequestwas bounded byRecord<string, unknown>. Interfaces do not get implicit index signatures in TypeScript, so a well-typed interface fails that bound with:This surfaced downstream as cloudflare/agents#1886 (
getAgentByName(ns, name, { props: config })rejecting interface-typed props) — the agents SDK inherits these bounds throughServerandgetServerByName, so the root fix belongs here.Fix —
objectbounds, noany, no castsProps extends object = Record<string, unknown>onServer,getServerByName, androutePartykitRequest. Interfaces satisfyobjectnatively; defaults stayRecord<string, unknown>so untyped usage still reads props values asunknown. Props is only ever treated as an opaque JSON bag at runtime (encodeProps/decodePropsalready type itunknown), so nothing behavioral changes.T extends Server<Env, object> = Server<Env>ongetServerByName/routePartykitRequest. Two things forced this: the#_propsprivate field carriesPropscovariantly, so a subclass declaring interface Props failed the oldServer<Env>constraint (whose Props silently pinned to theRecorddefault); and the DO stub'ssetNameparameter resolves from the constraint, sooptions.propswouldn't flow without it. The default staysServer<Env>, keeping the return type for untyped callers identical.Repro / regression tests
New compile-time test
packages/partyserver/src/tests/props.test-d.ts— typechecked bycheck:typebut never executed (vitest only picks up*.test.ts). Written first and confirmed red on main with errors matching the report:Serverdeclared with interfacePropsgetServerByName/routePartykitRequestcalled with interface-typed propsonStartreceiving the interface typePropsVerification
npm run build && npm run checkfully green (sherif, oxfmt, oxlint, all 42 typecheck projects, all workspace test suites).Once this ships, cloudflare/agents can bump
partyserverand loosen its ownPropsbounds without any bridging (supersedes the approach in cloudflare/agents#1906, closed in favor of fixing it here).